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METHOD FOR MANAGING COMMERCE CONTEXTS 



CROSS REFERENCE TO RELATED APPLICATIONS 

This Application claims priority under 35 U.S.C. § 119(a) to Canadian Patent 
Application No. 2>432.616 filed June 17, 2003, which is hereby incorporated 
5 herein by reference in its entirety. 

TECHNICAL FIELD 

The present invention relates to data processing systems, and more 
particularly to a context switch and a process for managing commerce contexts in 
client sessions. 

10 BACKGROUND INFORMATION 

Modem Internet and web applications commonly require information about 
the user and user's activities to be maintained across multiple requests. For example, 
in a typical online store, the user is provided with a browseable catalog firom which 
items can be selected and added to a shopping cart. Once the user has added all the 
15 desired items to the shopping cart, the user may proceed to the checkout where an 
order for the items contained in the shopping cart may be placed. To accomplish this 
process, multiple client requests are required and the information from each request 
must be maintained across requests. 

A hypertext transfer protocol (HTTP) is used to access many resources on the 
20 Intemet. However, HTTP is a stateless protocol that defines the format of requests 
and corresponding responses but does not currently define a mechanism for 
maintaining state information. In a typical request, an HTTP user or client opens a 
connection with a server and requests some information or a resource. The server 
responds with the requested resource, if available, or an HTTP error status page. 
25 After the server's response, the connection is closed and the server does not maintain 
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any information about the client. Any subsequent request by the client is considered 
a fresh request with no relation to the previous request. 

Several q)proaches have been developed to maintain user information across 
requests and responses. These approaches use the notions of sessions and states. A 

5 session is a series of HTTP requests originating from the same client in the same 
browser instance or "working session." State refers to information relating to the 
previous requests and other business decisions that may be made in relation to these 
requests. Utihzing these approaches, an Internet or web application should be able to 
associate a state with each session. Two common methods of session management 

10 are cookies and Universal Resource Locator (URL) rewriting. Cookies and URL 
rewriting are known in the art. Other session management strategies are also known 
in the art. Generally, session management strategies use an associated session area to 
store information about the user session. 

Many modem Internet and web applications are modular in design. 
15 Modularity allows different aspects of an application to be developed independently 
from one another. The Model-View-Controller (MVC) design pattern is a common 
design paradigm used in developing modular applications. The MVC design pattern 
is known in the art. 

In many Internet and web applications, a user will typically have to navigate 
20 through a number of organizations. These organizations may be located in different 
domains. For example, in an electronic marketplace or e-marketplace enviroimient, a 
buyer in a supply channel may move between a manufacturer or supplier and 
distributors or resellers. Each of these organizations is referred to as a store. Each 
store will typically have its own commerce context, for example, a store context. 
25 Thus, when navigating between stores, it is necessary to manage the switch between 
store contexts. A simple shopping flow illustrates this problem. 

A typical shopping scenario for a supply channel may involve the following 

steps: 
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(1) A buyer visits the channel store main page; 

(2) Browses through the catalog; 

(3) Places an order for a product; 

(4) Receives a confirmation for the order; 
5 (5) Continues browsing for other products. 

The process steps described above may be given the following names: 
' Step (1) - StoreFrontDisplay 
Step (2) - ProductDisplay 
Step (3) - OrderProcess 
1 0 Step (4) - OrderDisplay 

Step (5) - ProductDisplay 

In this shopping scenario, the buyer moves back and forth between the 
channel and a suppUer store. In step (1), the StoreFrontDisplay displays the main 
page of the channel store. In step (2), ProductDisplay involves retrieving the 
15 product(s) firom the catalog of the channel store and rendering the product 

description(s). In step (3), OrderProcess involves placing the order in the suppUer 
store. In step (4), OrderDisplay retrieves the order and displays the order. This step 
can be performed in the channel store or the supplier store. In step (5) 
ProductDisplay, the buyer is in channel store browsing products from the catalog. 

20 To create a smooth shopping experience, there needs to be a way to manage 

the switch between these store contexts. Several methods of managing store contexts 
are known in the art. One method involves creating a store identifier or store ID for 
each store, and appending the store ID as a parameter in each of the URLs that are 
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called. The URLs would look something like this for the process steps described 
above: 

Step (1) . . ./StoreFrontDisplay?StoreID=c_storel 

Step (2) .../ProductDisplay?StoreID=c_storel&ProductID=... 

5 Step (3) . . ./OrderProcess?StoreID=s_store2.... 

Step (4) .../OrderDisplay?StoreID =s_store2 

Step (5) .../ProductDisplay?StoreID =c_storel&ProductID =... 

where c_storel is the store ID for the channel store and s_store2 is the store ID for the 
supplier store. 

10 A disadvantage of tiiis approach is that it requires web designers to hard code 

the store ID into URLs used in the Internet or web application. This additional 
complexity further complicates modular apphcation design. For example, hard 
coding URLs in an MVC application may affect the design of each of the model, 
view, and controller components. 

15 In view of these shortcomings, there exists a need for another method of 

managing commerce contexts. 
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SUMMARY OF THE INVENTION 

The present invention provides a method for managing commerce contexts 
using direct and temporary commerce context parameters. 

In accordance with one aspect of the present invention, there is provided for a 
5 data processing system, a method for managmg commerce contexts, the data 
processing system being associated with a direct commerce context and a temporary 
commerce context, the data processing system being operatively coupled to memory 
having a session area, the method comprising the steps of receiving a client request 
associated with a commerce context parameter, and determining the commerce 
1 0 context associated with the commerce context parameter. 

In accordance with another aspect of the present invention, there is provided a 
computer program product having computer-readable medium tangibly embodying 
code for directing a data processing system to manage commerce contexts, the data 
processing system being associated with a direct conunerce context and a temporary 
15 commerce context, the data processing system being operatively coupled to memory 
having a session area, the computer program product comprising code for receiving a 
cUent request associated with a commerce context parameter, and code for 
determining the commerce context associated with the commerce context parameter. 

In accordance with a further aspect of the present invention, there is provided 
20 a data processing system for managing commerce contexts, the data processing 
system being associated with a direct conmierce context and a temporary commerce 
context, the data processing system being operatively coupled to memory having a 
session area, the data processing system comprising means for receiving a client 
request associated with a commerce context parameter, and means for determining 
25 the conmierce context associated with the commerce context parameter. 

In accordance with yet a further aspect of the present invention, there is 
provided a computer data signal embodied in a carrier wave and having means in the 
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computer data signal for directing a data processing system to manage commerce 
contexts, the data processing system being associated with a direct conmierce context 
and a temporary commerce context, the data processing system being operatively 
coupled to memory having a session area, the computer data signal comprising a 
5 component in the computer data signal for receiving a client request associated with a 
commerce context parameter, and a component in the computer data signal for 
determining flie commerce context associated with the commerce context parameter. 

Other aspects and features of the present invention will become apparent to 
those ordinarily skilled in the art upon review of the following description of specific 
10 embodiments of the invention in conjunction with the accompanying figures. 



6 



CA920030047US1 



PATENT 



BRffiF DESCRIPTION OF THE DRAWINGS 

Reference will now be made to the accompanying drawings which show, by 
way of example, embodiments of the present invention, and in which: 

FIG. 1 is a schematic diagram of a computer system suitable for practicing the 
5 invention; 

FIG. 2 is a schematic diagram of a server for the computer system of FIG. 1 
and which is connected to the computer system; 

FIG. 3 is a block diagram of a data processing for the computer system of 

FIG. 1; 

10 FIG. 4 is a block diagram of one embodiment of a commerce context switch 

implemented according to the present invention; 

FIG. 5 is a schematic diagram of an electronic marketplace in which the 
present invention may be implemented; 

FIG. 6 is a schematic diagram of one embodiment of a commerce context 
1 5 switch implemented according to the present invention; 

FIG. 7 is a flowchart showing the steps in the operation of the commerce 
context switch of FIG. 6; 

FIG. 8 is a flowchart showing a process for handling commerce context 
parameters by the commerce context switch of FIG. 6; 

20 FIG. 9 is a flowchart of the procedure for determining the commerce context 

at the end of a client request; 

FIG. 10 is a flowchart of the procedure for detennining the commerce context 
in the session area at the end of a client request; and 

FIG. 1 1 is a flowchart of a shopping scenario. 
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DETAILED DESCRIPTION OF THE EMBODIMENTS 

The following detailed description of specific embodiments of the present 
invention does not limit the implementation of the invention to any particular 
computer programming language. The present invention may be implemented in any 

5 computer progranmiing language provided that the operating system provides the 
facilities to support the requirements of the present invention. In one embodiment, 
the present invention is implemented, at least partly, in the Java computer 
programming language. Any limitations presented herein as a result of a particular 
type of operating system or computer programming language are not intended as 

10 limitations of the present invention. 

Reference is first made to FIG. 1, which shows a computer system 20 upon 
which the present invention is implemented. The computer system 20 includes a 
server 22 and clients 24 which are interconnected by a network 30. The server 22 
may be modeled as a number of server components including an application or 

15 business logic server, web server, graphical user interface server, and a database 
server or resource manager. The cUents 24 include computers, data processing 
systems, handheld portable devices, or computer networks. The clients 24 may be the 
same or different. In one embodiment, the network 30 is the Internet or World Wide 
Web (WWW). In such cases, the client devices are equipped with appropriate web 

20 browser software such as Intemet Explorer™ firom Microsoft Corporation or 
Netscape's Navigator™, and the application servers are equipped with appropriate 
HTTP server software, such as the WebSphere™ product fi-om IBM. 

The computer system 20 fiirther includes resources 32 connected to the 
network 30. The resources 32 include storage media, databases, for example, a 
25 relational database such as the DB2™ product from DBM, a set of XML (extensible 
Markup Language) documents, a directory service such as a LDAP (Lightweight 
Directory Access Protocol) server, and backend systems. The interface between the 
server 22 and the resources 32 comprises a local area network, Intemet, or a 
proprietary interface. The resources 32 are accessed by the server 22 and the clients 
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24. Any of the server 22, the clients 24, and the resources 32 may be located 
remotely from one another or may share a location. The configuration of the 
computer system 20 is not intended as a limitation of the present invention, as will be 
understood by those of ordinary skill in the art from a review of the following 
5 detailed description. 

Referring now to FIG. 2, a server in the computer system 20 will be described 
in more detail. The server 23 comprises a web application server compliant with the 
Java Version 2 Enterprise Edition (J2EE) platform such as the WebSphere™ product 
from IBM. A cUent 25 connects to the server 23 via the Internet or WWW. A user 
interface 26 is presented to the cUent 25, using JavaServer Pages (JSPs) and servlets. 
Using JSP technology makes it easy for user interface developers to present 
dynamically generated pages to any chent equipped with an Internet browser. 
Servlets give more sophisticated developers of Java-based applications the ability to 
implement dynamic presentations completely in the Java programming language. A 
business logic module 28 is implemented on the server 23 using Enterprise JavaBean 
components (EJB) for the object layer. WebSphere™ and other J2EE-compUant 
application servers provide an organization that allows user interface functions to be 
separated from the business logic module 28 on the application server 23. Those 
skilled in the art will recognize that many computing platforms, operating systems, 
and enterprise application server suites may be used with the present invention 
without departing from the scope of the invention. 

Referring now to FIG. 3, a data processing system 50 in the computer 
system 20 is now described in more detail. The data processing system 50 includes a 
processor 52, a memory 54, a display 56, and user input devices 58 such as a 
25 keyboard and a pointing device (e.g. mouse), and a communication interface (not 
shown) for communicating with the network 30 (FIG. 2). An operating system 
60 and application programs 62, 64 run on the processor 52. The memory 
54 includes random access memory ("RAM") 66, read only memory ("ROM") 68, 
and hard disk 70. The data processing system 50 may be a client or a server. 
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Reference is now made to FIG. 4, which shows in a block diagram form an 
implementation for a conunerce context switch 100 according to the present 
invention. The conmierce context switch 100 is implemented in functional modules 
in the form of computer software or a computer program product and executed by the 

5 processor 52 (FIG. 3) during operation of the computer program product. The 
commerce context switch 100 is implemented in an appUcation 101 and comprises a 
controller module 102, a model module 104, and a view module 106. A user 
interface 105 allows a user to communicate with the controller module 102. The 
model module 104 is unplemented usmg a Command pattem 103 that operates on 

1 0 Enterprise Java B eans. 

The application 101 uses the MVC (Module-View-Controller) design pattem 
to handle client requests and responses. The controller module 102 determines which 
operation to perform and the proper execution context for each request based on the 
request parameters and session information and data. This execution context is 
15 referred to as a command context. The command context is passed to the model 104 
and the view 106 modules. 

Referring still to FIG. 4, the controller module 102 communicates with the 
user interface 105 by interpreting requests and handling responses. The model 
module 104 contains business logic operations and conraiands, and accesses data and 

20 other resources. The view module 106 handles the presentation of information and 
data. In the operation of a web application, the controller module 102 interprets 
incoming HTTP requests and invokes the requested business logic operation or 
conmiand in the model module 104. Upon completion of the business logic 
operation, the controller module 102 updates the view module 106. The controller 

25 module 102 selects the next view to display based on the present data and resuU of the 
operation of the busmess logic 28 (FIG. 2). The controller module 102 then transmits 
the view to the user interface 105. 
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Some embodiments of the present invention may be implemented in a 
different application framework from that described below. The appUcation 
framework defines, at least in part, the order of events and operations performed by 
the application. In one embodiment, the application framework may allow the client 
5 request to contain information regarding the view to be invoked following the 
execution of a command or business logic operation. In this case, following flie 
execution of the command, the controller module 102 invokes the next view to be 
displayed based on the information in the client request. 

Reference is now made to FIG. 5, which shows an implementation of an 

10 electronic marketplace in which the present invention is operated. An e-marketplace 
place is an electronic forum that brings multiple buyers and sellers together in a way 
that provides efficient electronic trading of goods and services. An electronic 
marketplace or e-marketplace 201 is implemented on a server 202. The e- 
marketplace environment may be provided by a web application such as the 

15 WebSphere™ Commerce product from IBM. The e-marketplace 201 includes a 
direct store 203 having a catalog 204 and hosted supplier stores 206, indicated 
mdividually by references 206a, 206b,. . .206n. Stores hosted in this manner typically 
have a hosted storefront served using the IT infiBstructure of the direct or channel 
store 203 in the e-marketplace 201. The e-marketplace 201 may also be operably 

20 connected to a remote supplier store proxy server 208. The proxy server 208 is 
implemented on a separate server or on the server 202. A user interface 210 permits a 
client to connect with the server 202 and the e-marketplace 201. The user interface 
210 provides an Internet or web browser with which a cUent can navigate the e- 
marketplace 201. Non-hosted remote suppher stores 212, indicated individually by 

25 references 212a, 212b,... 212n, may connect to the e-marketplace 201 and the server 
202 over the Internet 213 via the proxy server 208. Typically, the hosted stores 206 
are in the same domain as the channel store 203 and the non-hosted stores 212 are in 
a different domain. 
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Reference is now made to FIG. 6, which shows a system implementation of a 
commerce context switch according to the present invention. A web browser 240 is 
used by a client in the e-marketplace 201 (FIG. 5). The browser 240 may be used to 
display a web page 242 in the e-marketplace 201 (FIG. 5) including buttons 244. The 
5 client may invoke an HTTP request using a command line invocation (not shown) in 
the browser 240 or by clicking on one of the buttons 244 using a mouse or similar 
pointing device. A typical HTTP request may take the form: 

http://<path>/<requestname>?<querystring> 

where <path> is the URL, <requestname> are names which may identify, for 
10 example, a business logic object or command to be performed in respect of the 
request, and <querystring> is query script in which query parameters are typically 
separated by an "&". 

Referring back to FIG. 5, in the e-marketplace 201, a buyer may navigate 
through a number of organizations or stores during a shopping flow. For example, 

15 the buyer may visit a direct or channel store 203 integrating a plurality of the supplier 
stores 206 and 212. The catalog 204 may be an aggregation of the product offerings 
of the hosted stores 206 and the remote stores 212, In this arrangement, some of 
supplier stores coupled to the direct store 203 may be hosted while other stores may 
be remotely located. Similarly, some of the supplier stores may be in a different 

20 domain from the channel store 203. Typically, each store will have its own 
commerce context, for example, a store context. A store may have its own business 
logic and its own operational data. Similarly, the user experience or "look and feel" 
of a store may be unique. For some stores, these and/or other aspects may be shared. 
A store context can contain information such as the store supported language, 

25 currency, directory for web assets such as store pages, and various store policies. 

When navigating between stores, it is necessary to manage the switch between 
store contexts. Typically, the client will switch between a direct or channel store 
context and supplier store contexts, for example the direct store 203 and a supplier 
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store 206 (FIG. 5). Usually, the client will return to the channel store after a 
transaction or event in a supplier store has been completed. For convenience, the 
channel store context is sometimes referred to as the direct store context, and the 
supplier store context is sometimes referred to as the temporary store context. Store 
5 context parameters are used to manage the switch between store contexts. Parameters 
StoreBD and ForStorelD are used to identify the channel store context and suppher 
store context respectively. The channel store context saved in the session is the 
Session StorelD. 

In a typical scenario, a client visits a channel store 203. The StorelD 
10 parameter is initially provided as a request parameter and stored in the session as the 
Session StorelD on return. The client then browses through other pages in the 
channel store 203 without specifying any StorelD parameters on the subsequent 
requests. The client may then visit a remote supplier store 212 in which case a 
ForStorelD parameter is used. When the client retums to the channel store 203 its 
15 StorelD is retrieved from the session and the proper store context is constructed. The 
command is aware of the StorelD but not its origin, e.g. whether the StorelD is 
derived from the request or the session area, or whether the StorelD refers to a direct 
store 203 or supplier store 206, 212. Similarly, the conmiand does not know if a 
supplier store is a hosted store 206 or a non-hosted remote store 212, e.g. in a 
20 different domain than the channel store 203. This information is handled by the 
business logic 28 of the command using the StorelD. 

Referring again to FIG. 6 and also the flowchart depicted in FIG. 7, the store 
context parameters are explained in more detail. When a cUent makes an HTTP 
request in the browser 240, the controller module 102 receives the request (step 302 
25 in FIG. 7) and retrieves any request parameters and session information and data 
(step 304 in FIG. 7). The controller module 102 creates a command context 246 
associated with the request (step 306 in FIG. 7). The command context 246 is created 
fresh for each request and does not maintain information across requests. In this 
manner, the command context 246 is stateless. A command 248 is associated with 
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the client request and the command context 246. The command 248 represents the 
client request, for example, the requested business logic operation. The command 
context 246 contains the information required to execute the command 248 such as 
the StorelD. By way of example, a client may make the following HTTP request: 

5 http://www.shoe.com/ProductDisplay?StoreID=203&ProductID=ABC 

where "StorelD" and "ProductID" are request parameters and "ProductDisplay" 
represents the business logic command tiiat is called by the request. 

The client request may contain one or more store context parameters, or no 
store context parameters. Table 1 shown below sunraiarizes the combinations of 
10 store context parameters that may be included in the request. Using the request 
parameters and session information and data, the value of the StorelD to be stored in 
the conmiand context 246 is determined (step 308 in FIG. 7). 

A session area 250 provides a store for session data and information including 
store context information and the Session StorelD. The session area 250 persists 
15 across client requests. Session management is performed using cookies, however 
other session management strategies such as URL rewriting may be used so long as 
the implemented solution provides a session area 250. Depending on the session 
management solution adopted, the session area 250 may be located on the client 
device or the server. 

20 The controller module 102 (FIG 4) will construct a store context with the 

StorelD in the command context 246 (step 310 in FIG 7). Typically, the command 
context 246 will also contain some user information such as preferences. Commands 
are used to implement business logic. The controller module 102 (FIG 4) determines 
the command to execute based on the request name. Optionally, it can be based on 

25 the StorelD in the command context because we can have different business policies 
for different store. Next the command 248 will execute using the command context 
and the associated store context (step 312 in FIG 7). Using the command result, a 
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response is sent to the web browser 240 by the controller module 102 (step 314 in 
FIG. 7). In the case where the ForStorelD request parameter is present, following 
execution of the command, the application 101 has the option of passing the 
command context 246 to the view module 106 in its present state or changing the 

5 StorelD to the new session StorelD before passing it to the view. In the first case, the 
view will be displayed in the context of the ForStorelD of the supplier store. In the 
second case, the view will be presented in the context of the channel store. It should 
be noted that the framework of the present embodiment requires a store context 
parameter to be included in either the client request or the session area 250. If the 

10 session area 250 does not contain a Session StorelD and the client request does not 
include a StorelD or ForStorelD, the client request v/ill fail and the client will be sent 
an HTTP error status page. 



Table 1. Store Context Construction 
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X 
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15 

Referring now to FIG. 8, a process 319 for handling of the store context 
parameters is described in more detail. In a first step 320, the controller module 102 
(FIG. 4) receives an HTTP request. The controller module 102 (FIG. 4) operates 
using Java servlets. The controller module 102 (FIG. 4) then retrieves the request 
20 parameters and session data (step 322). If the request contains a ForStorelD 
parameter (decision block 324), the controller module 102 (FIG. 4) stores the 
ForStorelD parameter as the StorelD in the command context 246 (FIG. 6) (step 326). 
If a StorelD parameter is also present (decision block 327), the Session StorelD will 
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be set to the StoreE) in the request (step 328). If no StorelD parameter is present, the 
Session StorelD will remain unchanged. 

If no ForStorelD is present (decision block 324), tiie controller module 102 
(FIG. 4) determines if a StorelD is present (decision block 330). If a StorelD 
5 parameter is present, the controller module 102 (FIG. 4) stores the StorelD in the 
request as the StorelD in the command context 246 (step 332). Next, the controller 
module 102 (FIG. 4) stores the StorelD as the Session StorelD in the session area 250 
(step 334). 

If no StorelD is present (decision block 330), the controller module 102 
10 (FIG. 4) stores the Session StorelD as flie StorelD in the command context 246 (step 
336). If no Session StorelD is present (decision block 335), this will be an error 
situation and the client will be sent an HTTP error status page (step 337). 

Referring now to FIG. 9, a procedure 340 for determining the store context for 
the command context 246 is described in more detail. If the client request contains a 
15 ForStorelD parameter (decision block 342), the controller module 102 (FIG. 4) stores 
the ForStorelD parameter as the StorelD in the command context 246 (step 344). In 
this case, the store context constructed is that of a suppUer store. 

If no ForStorelD is present (decision block 342), the controller module 102 
(FIG. 4) then determines if a StorelD is present (decision block 346). If a StorelD 

20 parameter is present, the controller module 102 (FIG. 4) stores the StorelD in the 
request in tiie command context 246 (step 348). The store context is constructed 
based on the StorelD request parameter. If no StorelD parameter is present (decision 
block 346) but a Session StorelD is present, the controller modules 102 (FIG. 4) 
stores the Session StorelD in the command context 246 (step 349) and the store 

25 context is constructed based on the Session StorelD. If no Session StorelD is present 
(decision block 345), this will be an error situation and the chent will be sent an 
HTTP error status page (step 347). 
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Referring now to FIG. 10, a procedure 359 for determining the store context 
in the session area 250 at the end of the request will be explained in more detail. If a 
StorelD parameter is present in the client request (decision block 360), tiie Session 
StorelD will be changed to the StorelD at the end of the request processing (step 
5 362). If no StorelD is present in the request, the Session StorelD at the end of the 
request processing will be the Session StorelD currently in the session area 250. 

Reference is next made to FIG. 11, which illustrates the steps for an 
exemplary shopping scenario in the e-marketplace 201 in accordance with the present 
invention. As in many online stores, clients are provided with a browseable product 
10 catalog 204 (FIG. 5) from which items can be viewed. In this example, the client has 
opened a new session in the web browser 240 (FIG. 6). In a first step 402, the buyer 
visits the main page of a channel store 203 integrating a plurality of supplier stores 
which may be located locally or remotely. The URL for this action may appear as 
follows: 

15 http://www.onlinestores.com/StoreFrontDisplay?StoreID=203 

Because this is a new session, there is no StorelD in the session area 250 (FIG. 6). 
The controller module 102 (FIG. 4) retrieves the StorelD parameter from the request 
and stores it in the command context 246 (FIG. 6). The store context is then 
constructed based on the StorelD and the StoreFrontDisplay command is executed. 
20 The resultant storefront view is generated and sent to the web browser 240 (FIG. 6). 
The Session StorelD is then set to the StorelD. The Session StorelD is now a 
persistent global variable available in the session. 

The buyer may then browse the catalog 204 (FIG. 5) for products to order. 
Next in step 404, the buyer selects a product to be displayed. The URL for this action 
25 may appear as follows: 

http://www.onlinestores.com/ProductDisplay?ProductID=ABCl 
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where ProductlD is a parameter identifying a product. The controller module 102 
(FIG. 4) retrieves the ProductDD parameter from the request. The client request does 
not include a StorelD so the controller module 102 (FIG. 4) retrieves the Session 
StorelD from the session area 250 (FIG. 6) and stores it as the StorelD in the 
5 command context 246 (FIG. 6). The store context is then constructed using the 
StorelD and the ProductDisplay conraiand is executed. The resultant product display 
view is then generated and sent to the web browser 240 (FIG. 6). 

Next in step 406, the buyer chooses to .order the product "ABCl". This 
product belongs to supplier store "20". The URL for this action may appear as 
10 follows: 

http://www.onlinestores.com/OrderProcess?ForStoreID=20&ProductID=ABCI 

In this case, a ForStorelD is present so the OrderProcess command will be executed 
in a supplier store context rather than the channel store context. The confroUer 
module 102 (FIG. 4) retrieves the ForStorelD parameter from the request and stores it 
15 as the StorelD in the command context 246 (FIG. 6). The store context is then 
constructed using the StorelD and the OrderProcess command is executed. The 
resultant view is then generated and sent to the web browser 240 (FIG. 6). 

Next in step 408, an order confirmation is displayed. The URL for this action 
may appear as follows: 

20 http://www.onlinestores.coni/C)rderDisplay?ForStbreID=20&ProductID=ABCl 

The confroUer module 102 (FIG. 4) retrieves the ForStorelD parameter from the 
request and stores it as the StorelD in the command context 246 (FIG. 6). The store 
context is then constructed using the StorelD and the QrderDisplay command is 
executed. The resultant view is then generated and sent to the web browser 240 
25 (FIG. 6). 
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Next in stq) 410, the buyer is returned to browsing in the catalog 204 (FIG. 5). 
The URL for this action may appear as follows: 

http://www.onlinestores.coni/ProductDisplay?ProductID=ABCl 

The controller module 102 (FIG. 4) retrieves the ProductID parameter from 
5 the request. Because there is no store context parameter specified in the request, the 
controller module 102 (FIG. 4) retrieves the Session StorelD from the session area 
250 (FIG. 6) and stores it as the StorelD in the command context 246 (FIG. 6). The 
store context is then constructed using the Session StoreED and the ProductDisplay 
command is executed. The resultant product display view is then generated and sent 
10 to the web browser 240 (FIG. 6). 

It will be appreciated by one of ordinary skill in the art that application 
frameworks different from that described above may be used without departing from 
the scope of the present invention. For example, in another framework, a login 
operation may be performed prior to the StoreFrontDisplay operation. This login 

15 operation may store the StorelD parameter in the session area 250 prior to the step of 
displaying the requested storefront. Allowance for variation in the firamework 
permits more customizable application design. For example, after the completion of 
an event, designers may choose to display an order confirmation which, may be 
performed in the suppUer store or channel store, or the cUent may be retumed to 

20 browsing the catalog in the channel store. Also, depending on tiie application 
framework implemented, some command parameters, for example the view 
parameters, may be included in the HTTP request or hard coded into the business 
logic of the command. It will also be appreciated by one of ordinary skill in the art 
that the method of managing store contexts provided by the present invention may be 

25 used for other e-marketplace operations, for example, a request for quotations (RFQ). 
Further, the present invention may be used to manage other commerce information 
that requires a temporary switch such as locale, language or ciirrency information. 
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The present invention may be embodied in other specific forms without 
departing firom the spirit or essential characteristics thereof. Certain adaptations and 
modifications of the invention will be obvious to those skilled in the art. Therefore, 
the presently discussed embodiments are considered to be illustrative and not 
5 restrictive, the scope of the invention being indicated by the appended claims rather 
than the foregoing description, and all changes which come within the meaning and 
range of equivalency of the claims are therefore intended to be embraced therein. 
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